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ABSTRACT 

Group  collaboration  in  distributed  multimedia  environments  ex¬ 
tends  gradually  to  larger  groups  and  wide-area  networks.  While 
reliable  multicasting  has  made  significant  advancements  in  re¬ 
cent  years,  effective  mechanisms  to  synchronize  and  coordinate 
work  within  large  multicast  groups  and  across  long  distances  are 
still  lacking.  Group  coordination  is  here  understood  as  the  me¬ 
diated  access  to  shared  remote  resources  in  synchronous  group- 
work,  as  for  example  in  telecollaboration  and  distributed  simu¬ 
lation  environments,  complementing  protocols  for  group  mem¬ 
bership,  media  synchronization  and  reliable  ordered  multicast.  A 
comparative  analytic  model  for  known  classes  of  group  coordina¬ 
tion  mechanisms,  ranging  from  socially  mediated  control  to  floor 
control  in  ring  and  tree  topologies,  is  presented.  It  is  shown  that 
hierarchical  group  coordination  is  the  most  efficient  and  scalable 
approach  to  date.  Based  on  these  findings,  a  novel  protocol  is 
described,  which  dynamically  organizes  participants  in  a  multi¬ 
level  control  tree  and  aggregates  resource  sharing  directives  on 
the  paths  between  interacting  stations. 

1  INTRODUCTION 

Increasing  deployment  of  IP-multicast  [6]  has  brought  a  new  gen¬ 
eration  of  collaborative  multimedia  applications  to  mainstream 
computing.  While  previous  collaboration  tools  were  proprietary, 
monolithic,  and  designed  for  small-scale  collaboration  in  local 
area  networks,  newer  applications  are  geared  towards  larger  ses¬ 
sions  with  wide  geographic  range.  For  example,  distributed  in¬ 
teractive  simulations  and  distance  learning  sessions  can  easily  in¬ 
volve  hundreds  of  participants.  Although  reliable  multicasting 
and  multicast  routing  technology  have  advanced  considerably,  ef¬ 
ficient  group  coordination  support  for  applications  characterized 
by  synchronous  and  wide-area  groupwork  is  still  lacking. 

Our  goal  is  to  extend  support  for  dynamic  group  coordina¬ 
tion  to  wide-area  networks  and  large  multicast  groups,  character¬ 
ized  by  intermittent  connectivity  and  heterogeneous  multimedia 
information.  The  central  idea  behind  group  coordination  pro¬ 
tocols  is  to  establish  a  resource-sharing  discipline,  counter  end- 
application  misbehavior,  and  incorporate  end-user  demand  for  a 
specific  Quality-of-Service,  allowing  to  throttle  bandwidth  uti¬ 
lization  and  impacting  informed  resource  allocation.  It  is  still  a 
subject  of  controversy,  whether  group  coordination  services  are  to 
be  tailored  to  the  application-level,  or  whether  they  should  be  of¬ 
fered  as  a  middleware  component,  which  a  variety  of  applications 
demanding  for  resource  cooperation  can  tap  into.  To  this  date,  a 
variety  of  group  coordination  protocols  have  been  proposed  un¬ 
der  different  names,  but  have  not  been  specified  in  more  detail, 
compared,  or  placed  in  a  consistent  methodological  framework. 

We  regard  coordination  of  group  activities  on  shared  resources 
as  a  distributed  middleware  service  tailored  toward  the  semantics 
of  the  media  involved,  rather  than  specific  applications.  We  focus 
in  this  paper  on  a  particular  form  of  group  coordination,  known  as 
floor  control.  By  being  granted  a  “floor”,  a  user  attains  a  permis¬ 
sion  for  exclusive  usage  of  a  resource.  Floor  allocation  establishes 
clear  rules  for  turn-taking,  and  prevents  race  conditions,  indefinite 
resource  holding,  and  unfairness  in  resource  access  patterns.  Par¬ 
ticipating  stations  agree  on  a  specific  floor  policy,  concerning  ser¬ 
vice  order  and  priorities.  The  spectrum  of  control  can  range  from 


lenient  to  strict,  reflecting  characteristics  of  tasks  and  interaction 
styles,  such  as  user  roles,  usage  quotas,  or  resource  contention  pe¬ 
riods.  As  a  component  within  a  general  coordination  architecture 
for  many-to-many  groupwork,  floor  control  coexists  with  proto¬ 
cols  for  reliable  ordered  multicast  and  media  synchronization  at 
a  sub-application  level.  Orchestration  of  multiparty  groupwork 
with  fine-grained  and  fair  floor  control  is  an  open  research  prob¬ 
lem.  In  this  paper,  we  offer  a  fresh  look  on  this  topic  by  making 
the  case  for  hierarchical  floor  control. 

The  remainder  of  the  paper  is  organized  as  follows:  Section  2 
discusses  cornerstones  of  related  work.  Section  3  presents  a  brief 
overview  and  comparison  of  existing  classes  of  group  coordina¬ 
tion  protocols.  We  find  that  floor  control  over  a  shared  propa¬ 
gation  tree,  corresponding  to  the  underlying  end-to-end  reliable 
multicast  tree,  represents  the  most  scalable  and  efficient  way  to 
store  and  forward  control  information.  In  particular,  it  allows  to 
exploit  the  hierarchical  nature  of  multicast  groups,  supports  se¬ 
lective  control  packet  dissemination  to  multicast  subgroups,  and 
distributes  load  about  floor  state  keeping  across  the  multicast  tree, 
without  compromising  ease  of  implementation.  Section  4  de¬ 
scribes  the  operation  of  the  Hierarchical  Group  Coordination  Pro¬ 
tocol  (HGCP),  a  novel  approach  for  floor  control  in  shared  prop¬ 
agation  trees.  Section  5  concludes  the  paper. 

2  RELATED  WORK 

Coordination  problems  such  as  initiation  conflicts  and  resource 
competition  in  multimedia  conferencing  have  been  reported  in 
[9].  Early  efforts  on  coordination  of  group  activities  led  to  the 
conception  of  floor  control  for  networked  databases  and  telecol¬ 
laboration  systems  [20].  Various  precursors  of  collaborative  ap¬ 
plications  [2,  5,  21,  23]  contained  some  form  of  proprietary  floor 
control  for  small  sessions  with  broadcast  of  control  information 
and  centralized  coordination.  The  centralized  method  is  compara¬ 
ble  to  a  sender-initiated  multicast  solution,  which  severely  limits 
the  capacity  of  a  group  coordination  system.  First,  one  station 
must  maintain  and  process  a  large  amount  of  state  information 
associated  with  each  resource  and  floor  contender.  Second,  the 
sender  as  the  floor  controller  must  process  many  floor  requests 
in  a  short  time  and  may  corrupt  the  entire  session,  if  failing.  An 
alternate  mechanism  has  been  proposed  in  the  teleconferencing 
architecture  by  Aguilar  et  al.  [1],  in  which  a  distributed,  task- 
activated  floor  control  for  teleconferencing  is  used,  as  a  high-level 
analogy  to  collision-sensing  in  channel  access.  In  Yavatkar  and 
Lakshman’s  approach  [25],  floor  control  is  understood  as  a  trans¬ 
port  level  service,  realized  as  a  token-based  concurrency  control 
scheme  for  media  flows,  which  has  been  implemented  on  top 
of  the  reliable  multicast  protocol  XTP.  Lately,  floor  control  has 
appeared  in  a  variety  of  commercial  and  experimental  systems. 
For  example,  the  MBone  application  suite  has  been  enriched  by 
a  moderated  bulletin  board  [15],  which  allows  users  in  a  larger 
scaled  conference  to  post  questions  and  receive  attention  from 
specific  participants.  Amir  et  al.  [3]  suggest  to  intertwine  floor 
control  with  a  rate-adaptation  mechanism,  which  throttles  media 
stream  transmission  according  to  the  interest  or  capabilities  of  a 
heterogeneous  receiver  set.  Only  sources  being  granted  the  floor 
are  allowed  to  consume  bandwidth,  and  floor  control  directives 
can  be  used  to  reserve  future  bandwidth  shares. 
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3  GROUP  COORDINATION  PARADIGMS 


Group  Coordination 
Mechanisms 


We  propose  a  basic  taxonomy  which  divides  known  group  coor¬ 
dination  algorithms  into  two  classes:  implicit  group  coordination 
(IGC)  and  explicit  group  coordination  (EGC)  algorithms. 

Taxonomy 

IGC  algorithms  mark  the  state  of  resource  usage  with  assertions 
on  local  variables  determined  through  one  or  more  rounds  of  mes¬ 
sages  or  probing  of  remote  resources’  states.  Since  no  token  en¬ 
tity  is  explicitly  exchanged,  such  algorithms  are  also  referred  to  as 
“permission-based”.  The  challenge  for  this  class  lies  in  the  glob¬ 
ally  consistent  state  keeping  of  local  assertions.  IGC  schemes  are 
inherently  contention-based,  since  sites  must  actively  compete  for 
a  floor.  Disadvantages  of  IGC  are  the  need  for  continuous  sensing 
and  the  failure-prone  observation  of  remote  resource  states,  either 
by  man  or  machine,  with  a  strong  likelihood  of  collisions  due 
to  network  latency,  or  lack  of  coordination.  As  a  consequence, 
contending  stations,  being  unaware  of  each  others’  immediate  ac¬ 
tions,  may  experience  collisions  by  trying  to  access  a  resource  at 
the  same  time. 

In  contrast,  EGC  algorithms  explicitly  exchange  a  unique  to¬ 
ken  among  sites.  Obtaining  this  token  symbolizes  the  right  to  ac¬ 
cess  a  resource,  thereby  dispersing  floor  contention  by  regulated 
passing  of  permission  place-holders.  Hence,  this  class  is  also  re¬ 
ferred  to  as  “token-based”.  In  addition  to  the  token  being  passed 
among  sites,  control  messages  are  exchanged  to  request,  deny,  re¬ 
serve,  or  grant  the  token,  depending  on  the  control  scheme  used. 
A  shortcoming  of  EGC  schemes  is  the  higher  cost  of  token  track¬ 
ing,  in  order  to  ensure  token  uniqueness  and  authenticity.  EGC 
schemes  generally  operate  on  a  defined  infrastructure,  which  log¬ 
ically  organizes  the  receiver  set. 

Both  classes  operate  based  on  the  dichotomy  between  a.  floor 
holder  (EH),  which  designates  the  current  legitimate  user  of  a  re¬ 
source,  and  a  floor  coordinator  (EC)  for  that  resource,  which  de¬ 
termines  the  legitimate  floor  holder  at  a  given  time.  Often,  the 
FH  is  also  the  EC.  We  assume  that  a  generic  group  coordination 
protocol  uses  the  following  basis  set  of  control  messages:  a  sta¬ 
tion  sends  a  FRQ  (floor  request)  to  the  EC  to  demand  access  to 
a  resource;  the  EC  either  replies  with  FGT  (floor  grant)  to  grant 
permission  to  access  the  resource  (when  the  floor  is  free),  or  FDY 
(floor  deny)  to  signal  that  the  floor  is  taken  or  reserved;  a  station 
transmits  a  FRL  (floor  release)  message  to  relinquish  the  floor. 
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Figure  2:  Group  coordination  mechanisms. 


perspective.  The  goal  is  to  assess  how  much  overhead  is  intrinsic 
to  the  various  protocols  with  regard  to  control  state  management, 
based  on  topology  and  signaling.  We  take  into  consideration  an 
average  floor  request  arrival  rate,  task  length,  and  network  prop¬ 
agation  delay.  In  our  model,  a  collaboration  session  Cs  =  (5,  L) 
in  a  computer  network  consists  of  a  set  of  stations  S  (sites,  nodes) 
and  a  set  of  links  L  G  S  x  S.  Each  station,  in  an  intranetwork 
or  internetwork,  hosts  a  session  member  (user,  process),  serves 
remote  stations  with  local  resources,  and  is  client  for  remote  re¬ 
sources.  Links  are  either  reliable  (no  loss,  but  possibly  delayed 
delivery),  resilient  (timely  delivery,  but  likely  some  loss),  or  with¬ 
out  service  guarantees. 

For  reasons  of  tractability,  we  make  the  following  assump¬ 
tions:  the  underlying  dissemination  model  is  broadcast,  i.e.,  a  host 
sends  each  message  only  once  to  the  network  interface,  where  it 
is  IP-multicast  to  the  receivers;  message  delivery  between  hosts  is 
FIFO,  and  no  station  failures  occur;  user  interface  and  host  pro¬ 
cessing  overhead  are  negligible  for  each  station;  the  interarrival 
rate  of  floor  requests  is  Poisson,  given  that  there  is  no  indication 
for  cross-correlations  between  subsequent  floor  requests;  floor  al¬ 
location  is  greedy,  that  is,  the  first  registered  request  is  fulfilled, 
and  others  are  discarded  and  may  be  resubmitted  later;  finally,  the 
floor  holding  time  to  execute  a  task  is  on  the  average  the  same  and 
normalized  to  unity. 
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Table  1:  Analysis  parameters. 


Figure  1:  Group  coordination  geometries. 

The  crucial  difference  between  algorithms  lies  in  the  assign¬ 
ment  of  these  roles  to  various  nodes  during  a  session,  which  im¬ 
pacts  the  routing  of  control  messages.  Figure  1  depicts  typical 
coordination  scenarios,  where  a  circled  entity  marks  the  FC  or 
FH:  (a)  several  participants  Pi  try  to  gain  control  of  a  centralized 
resource  R  with  limited  or  no  coordination;  (b)  Pi  communicate 
directly  with  each  other  in  order  to  obtain  a  consensus  about  floor 
holdership;  (c)  a  ring  structure  linearizes  interaction  and  control 
passing  between  pairs  of  nodes;  (d)  one  centralized  station  serves 
as  FC  in  a  star-topology,  which  is  a  one-level  subcase  of  (e);  (e) 
control  messages  are  propagated  along  branches  of  a  multi-level 
tree  topology  towards  the  current  FH. 

The  goal  for  all  algorithms  is  the  correct  and  efficient  deter¬ 
mination  of  the  FC  and  FH  per  resource  at  every  turn  in  a  col¬ 
laborative  session.  The  taxonomy  in  Figure  2  corresponds  to  the 
constellations  in  Figure  1 . 

Comparative  Analysis 

Our  analytic  comparison  of  known  classes  of  group  coordination 
protocols  is  a  first  attempt  to  characterize  the  efficacy  of  interac¬ 
tive  behavior  of  people  and  processes  from  a  resource  contention 


Table  1  summarizes  the  notation,  iz  is  the  time,  during  which 
a  station’s  attempt  to  access  a  resource  can  be  intercepted  by  an¬ 
other  station.  We  assume  for  all  protocols  that  r  signifies  the 
average  propagation  delay  for  multiple  routing  hops  between  sta¬ 
tions  coalesced  into  one  hop.  A  packet  must  hence  traverse  on  the 
average  the  same  number  of  hosts  on  the  path  from  the  sender  to  a 
group  of  receivers.  G  =  5  x  A  is  the  offered  request  load  on  floors, 
including  new  and  previously  denied,  and  resubmitted  floor  re¬ 
quests.  For  IGC  schemes,  7  denotes  the  average  contention  pe¬ 
riod,  whereas  for  EGC  schemes,  7  is  the  average  processing  time 
per  control  packet. 
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Figure  3:  Conceptual  turn-taking  model. 

A  turn-taking  model,  shown  in  Figure  3,  serves  as  the  concep¬ 
tual  foundation  for  our  analysis.  A  turn  consists  of  three  stages,  a 


contention  period  X,  an  activity  period  A,  and  an  idle  time  I.  A 
timeline  for  a  turn  shows  how  long  it  takes  on  the  average  for  an 
individual  station  to  acquire  a  specific  floor.  The  various  schemes 
allocate  these  periods  differently  to  grant  and  revoke  floors  on  re¬ 
sources.  Based  on  this  model,  we  define  the  efficacy  rj  group 
coordination  protocol  with  multicast  support  as  the  ratio  of  floor 
usage  time  vs.  overall  turn  length,  given  by  Eq.  1: 


T  X  +  A  +  I 

Incoordination  (ICIC)  refers  to  unawareness  about  other  sta¬ 
tions’  activities,  caused  by  minimal  user  interface  feedback  or 
high-latency  networks,  and  may  lead  to  completely  unsynchro¬ 
nized  resource  access.  This  is  the  case  for  early  collaboration 
systems  such  as  [20]  and  long-distance  conferencing  with  unpre¬ 
dictable  delays. 

Theorem  1  The  efficacy  of  ICIC  is 

VICIC  =  (2) 
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Figure  4:  ICIC  timeline. 

Proof:  Figure  4  shows  a  prototypical  turn  under  incoordina¬ 
tion.  The  proof  is  the  same  as  for  medium  access  in  an  ALOHA 
channel  [4].  Messages  can  intercept  each  other  during  contention, 
hence  the  vulnerability  interval  is  twice  the  task  length.  There¬ 
fore,  because  request  arrivals  are  Poisson,  the  probability  that  a 
task  is  successful  is  .  The  success  probability  times  the 

number  of  arrivals  in  one  activity  period  results  in  Eq.  2.  □ 

Social  Mediation  (ICSM)  leaves  floor  negotiation  to  social 
conformities  among  session  members  using  available  awareness 
cues.  If  there  is  remote  activity,  a  user  contending  for  the  floor 
withdraws  for  a  random  time  and  reclaims  the  floor,  when  the  re¬ 
mote  activity  subsides.  This  is  the  case  for  modem  POTS  confer¬ 
encing  systems.  Both  ICIC  and  ICSM  incur  no  implementation 
cost  with  regard  to  system-aided  coordination,  however,  reliabil¬ 
ity  is  low  and  likelihood  of  conflict  is  high.  It  is  possible  that  a 
single  host  and  user  become  moderator  and  floor  controller  for 
all  other  hosts,  creating  a  bottleneck  system-wise  and  user-wise 
for  reasons  mentioned  above,  if  many  receivers  demand  control 
decisions  from  this  one  host  at  the  same  time. 

Theorem  2  The  efficacy  of  ICSM  is 
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Figure  5:  ICSM  timeline. 

Proof:  A  prototypical  timeline  of  ICSM  is  depicted  in  Figure 
5.  The  success  probability  is  denoted  as  Ps,  the  failure  prob¬ 
ability  is  Py  =  1  —  Ps.  The  average  utilization  period  lasts 
JJ  =  5Ps,  and  the  length  of  the  average  busy  period  B  =  X  A 
is  determined  by  the  time  needed  to  handle  unsuccessful  floor  re¬ 
quests  in  the  failed  contention  period  X /  and  successful  requests 
in  Xs,  with  P  =  (1  —  Ps)Xf  -|-  PsXs-  y  is  the  time  needed 
to  sense  and  react  to  resource  states.  An  average  failed  turn  at¬ 
tempt  consists  of  a  geometrically-distributed  indefinite  number 


(L)  of  interarrival  times  of  floor  requests  with  duration  /  sec  (av¬ 
erage  time  between  failed  floor-request  arrivals),  plus  the  dura¬ 
tion  of  any  given  floor  request  (7').  The  values  for  L  and  /  have 
been  derived  in  [22].  Substituting  our  notation  in  these  results, 
we  obtain  L  =  and  /  =  (At)“^  —  e“^^/(l  —  re¬ 

spectively.  Accordingly,  the  average  time  of  a  failed  turn  attempt 

equals  Xy  =  +7^  +  t.  Ps  equals  the  probability 

that  no  activity  packet  arrives  in  a  vulnerability  period  v  of 
sec.,  i.e.,  Ps  =  P[0  packets  in  v\  =  A  successful  turn  is 

Xs  =  y  +  S  +  T.  Finally,  the  expected  idle  time  is  /  =  t  -|-  L. 
Substituting  into  Eq.  1,  we  obtain  Eq.  3.  □ 

Activity  Sensing  (ICAS)  is  a  special  class  of  floor  control  pro¬ 
posed  in  [8],  where  shared  activities  on  resources  are  monitored 
by  a  background  process  at  the  session  layer,  in  order  to  sense 
which  site  currently  operates  on  the  resource.  This  mechanism  is 
comparable  to  collision  sensing  in  medium  access  control.  If  an 
ICAS  process  at  a  local  site  detects  remote  activity  on  a  resource, 
it  denies  the  local  user  the  floor,  until  remote  activity  subsides.  In 
that  way,  a  distributed  collective  of  activity  sensing  agents  ensures 
better  tracking  of  resource  states,  and  helps  to  prevent  conflicts. 
The  disadvantage  of  this  scheme  is  its  high  implementation  cost 
and  its  reliance  on  short  link  latencies,  which  makes  it  usable  only 
in  LANs. 

Theorem  3  The  efficacy  of  ICAS  is 
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Figure  6:  ICAS  timeline. 


Proof:  The  timeline  is  shown  in  Figure  6.  The  average  uti¬ 
lization  period  is  t7  =  5Ps,  with  Pg  =  P[0  packets  in  n]  = 
g-Ar  jjjg  average  length  of  a  successful  busy  period  is  sim¬ 
ply  54-7-1-  2t.  The  length  of  an  average  unsuccessful  activ¬ 
ity  period  consists  of  one  truncated  activity  lasting  7  sec,  fol¬ 
lowed  by  one  or  more  similarly  truncated  activities  sent  within 
time  Y  sec,  where  0  <  X  <1".  The  expected  value  of  Y  is 
Y  =  r—  7(1  —  6“^’’)  [22].  The  length  of  the  average  busy 
period  is  then  B  =  74- 2t—  74-e“^’'(54-r4-7).  The  average 
idle  interval  is  again  I  =  t  4-  Substitution  into  Eq.  1  yields 
Eq.  4.  □ 

The  class  of  explicit  group  coordination  comprises  three  pro¬ 
tocol  families,  as  well.  Common  to  all  families  is  the  exchange  of 
a  floor  token  symbolizing  exclusive  access  to  the  shared  resource. 
It  must  be  assured  that  token  transmission  is  reliable  and  that  all 
sites  execute  the  same  protocol  correctly  to  avoid  conflicts  based 
on  duplicated,  lost  or  forged  tokens. 

In  Fully-connected  Group  Coordination  (ECFC),  each  station 
is  directly  connected  to  every  other  station.  In  the  simplest  case, 
a  station  acquires  the  floor  by  sending  a  FRQ  to  the  other  n  —  1 
stations,  which  send  a  FGT  message  back  if  they  do  not  hold  the 
floor.  If  a  station  is  FH  for  this  floor,  it  sends  a  FDY  message,  and 
follows  up  with  a  FGT  as  soon  as  it  releases  the  floor.  If  several 
stations  ask  for  the  same  floor  from  each  other,  control  packet  se¬ 
quence  numbers  (or  another  election  mechanism)  determine  the 
next  FH.  The  complexity  of  ECFC  grows  quadratically  with  the 
number  of  hosts.  For  each  floor  transaction,  2{n  —  1)  messages 
are  required,  following  the  Ricart-Agrawala  mutual  exclusion  so¬ 
lution  [19].  Newer  quorum  or  tree-based  [18]  algorithms  for  ob¬ 
taining  an  exclusive  token  can  reduce  the  number  of  messages  to 
0{logn),  where  n  is  the  session  size.  However,  these  schemes  do 


not  scale  well,  since  the  network  can  easily  be  flooded  with  too 
many  control  messages,  and  significant  delay  variations  between 
hosts  can  eventually  deadlock  collaborative  turn-taking. 

Theorem  4  The  efficacy  ofECFC  is 

s 


minimal,  in  order  to  keep  the  number  of  hops  for  control  trans¬ 
missions  low.  A  special  case  of  ECTB  is  a  star-topology,  which 
is  a  tree  of  depth  one  with  a  root  and  n  —  1  descendants.  The 
moderator-driven  question  board  [15]  exemplifies  this  scheme. 
Such  a  centralized  scheme  suffers  as  a  communication  bottleneck 
primarily  from  overload  when  the  request  rate  increases.  In  our 
analysis,  focused  on  multicast  support  for  turn-taking,  we  did  not 
account  for  this  additional  individual  host  processing  cost. 
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Theorem  6  The  efficacy  of  ECTB  is 
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Figure  7:  ECFC  timeline. 

Proof:  The  timeline  for  ECFC  is  shown  in  Figure  7.  The  time 
per  station  to  send,  receive,  and  update  floor  information  with 
every  other  station  is  3(7  -I-  t).  An  extra  processing  time  e  from 
n  —  1  stations  must  be  added.  Substitution  into  Eq.  1  results  in 
Eq.  5.  □ 

In  Ring-based  Coordination  (ECRB),  a  token  rotates  in  a  well- 
defined  sequence  among  sites  and  holding  the  token  determines 
the  current  floor  holder,  with  two  subcases:  (a)  a  token  claim  can 
be  decided  upon  before  arrival,  or  during  the  arrival  hold-time,  or 
only  while  it  visits  the  local  station,  and  (b)  a  token  can  be  trans¬ 
ferred  immediately  after  a  forward  from  a  station  to  the  next  one 
in  the  ring,  or  only  after  the  releasing  station  received  an  acknowl¬ 
edgment.  ECRB  is  particularly  suited  to  ensure  totally  ordered 
and  atomic  delivery,  but  does  not  scale  well,  since  the  token  walk 
time  is  proportional  to  the  receiver  set.  In  addition,  the  prede¬ 
fined  traversal  order  may  cause  artificial  delays  in  the  interactions 
between  particular  stations.  A  token-ring  based  collaboration  sys¬ 
tem  has  been  evaluated  by  Pendergast  [17]. 

Theorem  5  The  efficacy  of  ECRB  is  given  by 
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Figure  8:  ECRB  timeline. 

Proof:  The  timeline  for  ECRB  is  depicted  in  Figure  8.  The 
average  utilization  is  again  JJ  =  5 Pc,  with  Pc  as  the  probability 
that  the  token  is  available  in  the  period  X  =  /3i  -I-  /32 .  This  period 
includes  the  time  7  needed  to  transfer  the  token  to  the  neighbor 
station.  The  token  cycle  time  is  a  function  of  the  session  size. 
On  the  average,  a  floor  token  has  to  cycle  through  half  the  ring 
to  be  transferred.  The  probability  that  a  floor  can  be  claimed  by 
a  user  is  =  1  —  Accordingly,  the  average  turn 

lasts  f  =  ^(r  -1-7-1- 132)  +  U.  The  idle  time  is  again  t  +  7. 
Substituting  T,  U  and  I  into  Eq.  1  yields  Eq.  6.  □ 

Tree-based  Coordination  (ECTB)  algorithms  conduct  floor 
management  in  a  logical  tree  structure.  Such  a  tree  may  reflect 
the  actual  multicast  routing  tree,  or  mirror  the  end-to-end  reliable 
multicast  tree.  Control  messages  are  passed  along  branches  of 
the  tree  in  a  parent-child  relation,  which  reflects  multicast  group 
membership.  No  specific  site  alone  is  hence  burdened  with  the 
obligation  to  make  floor  allocation  decisions,  and  tokens  can  wan¬ 
der  freely  across  the  tree  branches,  without  being  cast  into  a  spe¬ 
cific  traversal  order  other  than  what  multicast  group  membership 
expresses.  While  various  tree-based  reliable  multicast  protocols 
have  been  proposed  for  highly  scalable  conferencing  [12,  14,  24], 
no  group  coordination  mechanism  or  applications  have  been  de¬ 
veloped  yet.  The  goal  for  such  a  protocol  is  to  keep  the  tree  depth 
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Figure  9:  ECTB  timeline. 

Proof:  The  timeline  for  ECTB  is  depicted  in  Figure  9.  With 
multicasting,  a  request-reply  pair  takes  two  7  and  t,  plus  another 
r  to  signal  completion  of  the  turn.  A  close  correlation  between 
the  control  tree  and  the  end-to-end  multicast  tree  is  assumed.  The 
idle  period  is  again  t  -b  ■^.  Substituting  into  Eq.  1  gives  Eq.  7. 
Note  that  we  normalize  the  pathlength  for  a  generic  tree  coordi¬ 
nation  protocol  to  P  =  1,  assuming  that  the  host  tree  mirrors  the 
multicast  routing  tree.  Under  this  assumption,  each  of  the  dis¬ 
cussed  protocols  must  on  the  average  traverse  the  same  number 
of  hosts  on  the  path  from  the  sender  to  a  group  of  receivers.  □ 


Comparison  for  large  sessions  /  high  latency 
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Figure  10:  Efficacy  for  large  groups  and  high  link  latency. 

Results 

Traces  from  MBone  sessions  [13],  sampled  over  a  period  of  sev¬ 
eral  hundred  hours,  indicate  a  group  size  ranging  from  150  to 
over  550  participants.  As  a  snapshot  to  indicate  the  advantages 
of  tree-based  group  coordination.  Figure  10  plots  the  efficacy  of 
discussed  schemes  for  a  large  session,  n  =  300,  and  wide-area 
collaboration,  t  =  400ms.  Such  a  scenario  can  occur  for  Inter¬ 
net  collaboration,  with  an  assumed  latency  that  has  been  observed 
to  be  the  minimum  for  acceptable  audio  conferencing  quality  [9]. 

We  can  see  that  a  generic  tree-based  floor-control  protocol 
exhibits  superior  stability  and  scalability  with  regard  to  higher 
loads.  With  an  aggregated  control  scheme,  floor  control  remains 
effective  despite  a  large  number  of  directives  being  exchanged 
among  participants.  Since  such  a  protocol  taps  into  the  given 
infrastructure  of  a  pre-built  host  tree,  there  is  no  additional  setup 
cost.  A  more  comprehensive  analysis  and  thorough  discussion  of 
other  scenarios,  varying  group  size  and  latency,  can  be  found  in 
Ref.  [7]. 


4  PROTOCOL  DESCRIPTION 

We  outline  the  basic  operation  of  the  Hierarchical  Group  Coor¬ 
dination  Protocol  (HGCP).  For  a  more  detailed  description  and 
proof  of  correctness  for  HGCP  we  refer  to  [7].  Our  goal  is  to  ex¬ 
ploit  the  best-effort  delivery  mechanism  of  IP  multicast  in  a  scal¬ 
able  and  efficient  tree  protocol  for  reliable  group  coordination. 
The  protocol  consists  of  two  stages:  (1)  control  tree  construction, 
and  (2)  control  message  dissemination.  In  order  to  consistently 
account  for  floor  control  messaging,  we  assume  ordered  message 
delivery  between  hosts.  Ordering  in  multicast  trees  has  been  tack¬ 
led  for  example  by  Jia  [10]. 

We  distinguish  between  four  types  of  nodes  in  a  propagation 
tree:  the  source  node  is  the  current  FH  and  transmits  information 
to  the  receiver  set;  hop  nodes  are  positioned  on  the  path  from  the 
source  to  the  receivers,  and  are  called  extra  nodes,  if  they  are  not 
contained  in  the  receiver  set;  destination  nodes  are  members  of 
the  receiver  set.  Each  of  these  nodes  can  contend  for  any  floor 
at  any  time  and  become  FH.  In  a  multicast  collaboration  session 
with  multiple  floors  and  floor  holders,  it  is  not  practical  to  man¬ 
age  separate  control  trees,  one  per  floor.  Similar  to  the  concurrent 
reliable  multicast  scheme  proposed  in  [12],  we  hence  assume  a 
single  shared  control  tree  with  a  branching  factor  B,  which  can 
be  re-hung  as  a  control  tree  with  any  other  node  as  the  root  and 
FH,  while  preserving  the  property  that  all  nodes  have  B  children. 
Ideally,  the  control  tree  correlates  closely  to  the  multicast  rout¬ 
ing  tree,  as  built  by  multicast  routing  protocols  such  as  DVMRP, 
CBT,  orPIM[16]. 

We  focus  on  an  approach  comparable  to  receiver-initiated  mul¬ 
ticast  [12],  which  lets  contending  stations  in  the  group-coordinated 
session  maintain  state  information  about  a  particular  floor.  Floor 
state  information  can  hence  be  passed  along  between  contend¬ 
ing  stations,  without  requiring  the  controller  station  to  contact 
each  station.  For  this  purpose,  each  station  maintains  two  timers. 
Timer  one  is  employed  to  detect  whether  a  floor  control  message 
has  been  lost.  Timer  two  is  used  to  delay  repetitive  control  mes¬ 
saging  to  the  controller,  in  the  hope  that  a  near-by  station  is  able  to 
report  an  update  from  the  controller  station.  The  collective  state 
information  about  all  floors  is  hence  distributed  across  the  control 
tree.  Note  that  HGCP  is  independent  of  a  particular  reliable  mul¬ 
ticast  implementation,  but  relies  on  the  failure-free  transmission 
of  control  packets  rendered  by  such  a  protocol.  Transmission  of 
control  packets  concerning  floor  states  is  based  on  the  abstrac¬ 
tion  of  a  propagation  group,  which  consists  of  processes  (users, 
hosts)  scattered  in  the  network,  which  are  interested  in  coordi¬ 
nating  their  activities  on  a  particular  resource  set.  Propagation 
groups  can  be  built  by  tapping  into  the  information  provided  by  a 
session  directory  service. 

The  control  tree  of  HGCP  organizes  group  participants  into  a 
hierarchy  of  subgroups  or  coteries.  Each  such  coterie  has  a  group 
manager,  which  acts  as  a  representative  for  all  other  members  in 
the  group.  The  group  manager  is  responsible  for  querying  control 
states  of  floors  for  its  group  members.  Eor  reasons  of  simplicity 
and  more  efficient  group  coordination,  it  can  be  assumed  that  FC 
and  FH  are  identical  for  a  particular  floor  at  all  times.  If  multiple 
FH  are  allowed  in  parallel  for  a  particular  resource,  it  is  necessary 
to  separate  the  FC  and  FH  roles. 

A  construction  method  for  a  control  tree  for  group  coordi¬ 
nation  on  top  of  a  multicast  routing  tree  is  outlined  in  [12].  A 
node  X  in  the  resulting  hierarchical  acknowledgment  tree,  whose 
edges  are  directed  from  children  to  their  parents,  is  labeled  with  a 
unique  label  l{x),  which  is  the  prefix  of  all  children  of  x.  Label¬ 
ing  is  top-down,  and  the  maximal  length  of  labels  in  a  tree  reflects 
its  depth.  The  label  alphabet  can  consist  of  any  set  of  symbols 
with  a  defined  order  (in  the  simplest  case  integers).  Note  that 
labels  in  the  tree  remain  constant  for  the  lifetime  of  the  session, 
except  in  cases  when  nodes  fail  or  new  nodes  join  a  subtree.  Rare 
cases  when  relabeling  is  necessary  are  discussed  in  [12].  Adding 
a  node  in  the  tree  involves  only  the  new  node  as  a  child  and  its  par¬ 
ent,  while  deletions  require  relabeling  of  the  subtree  of  the  deleted 
node.  The  labeling  scheme  allows  for  implicit  routing  of  control 
messages,  nodes  can  remain  anonymous  in  the  interaction,  yet 
address  each  other  efficiently  by  using  label  prefix  comparison. 


and  only  a  single  tree  is  needed  for  concurrent  multicast.  Sup¬ 
port  for  implicit  labeling  and  routing  at  the  multicast  router  level 
has  been  proposed  by  Levine  and  Garcia-Luna  in  [11].  A  sample 
scenario  is  shown  in  Eigure  1 1 .  In  this  scenario,  a  ternary  control 
tree  is  labeled  from  alphabet  {0, 1,  2},  with  FH  =  d  located  at 
l{d)  =  110. 


Eigure  11:  Sample  HGCP  scenario. 


An  example,  how  control  relegation  works,  is  the  following: 
at  all  times,  nodes  maintain  a  local  record  about  the  labeled  posi¬ 
tion  of  the  EH  in  the  tree.  Any  node  can  assume  this  role,  when 
being  granted  the  floor.  A  control  directive  (CD)  is  a  tuple  of  the 
format 

{{Is},  {Id},  t,  TTL,  ID,  f) 

containing  an  ordered  list  of  source  labels  {h},  a  list  of  destina¬ 
tion  labels  {Id},  a  sequence  number  or  timestamp  t,  a  time-to-live 
TTL,  an  identifier  ID,  and  a  floor  /.  The  floor  field  /  allows 
to  discern  media  types,  priorities,  and  the  operational  semantics 
(e.g.,  access  control)  of  a  resource.  This  format  allows  to  send 
and  receive  composite  floor  directives  and  reduce  the  amount  of 
control  traffic,  which  is  particularly  critical  for  large  and  highly- 
interactive  sessions  with  many  floors  and  resources. 

Assume  that  node  a  with  /(a)  =  1001  wants  to  submit  a  FRQ 
CD,  and  finds  FH  =  d,  with  1{FH)  =  110,  in  its  local  record. 
The  request  percolates  up  in  the  tree  across  the  root  node  and 
down  on  the  right  branch  according  to  the  label  prefix  semantics. 
The  label  format  allows  for  self-routing  of  control  directives  and 
addressing  of  specific  nodes  in  the  multicast  group,  simply  by 
knowing  their  logical  address,  and  without  nodes  having  to  iden¬ 
tify  themselves  otherwise.  Until  FH  receives  a  FRQ,  it  multicasts 
resource  state  updates  to  its  immediate  neighbors,  which  forward 
the  information  to  the  session  remainder.  CDs  are  aggregated 
at  hop  or  extra  nodes,  by  coalescing  requests  or  responses  from 
neighbor  nodes  into  single  CDs  and  forwarding  them  accordingly. 
Concurrent  submissions  are  resolved  by  attaching  a  timestamp  to 
each  control  packet,  which  gives  preference  to  the  earliest  submit¬ 
ted  request.  Node  d,  after  completion  of  its  resource  operation, 
multicasts  back  a  FGT  message  to  node  a,  which  also  informs  all 
other  nodes  in  the  session  via  flooding  about  the  new  position  of 
FH  =  a.  Each  node  maintains  an  entry  for  each  floor  on  the  rela¬ 
tive  path  direction  (next  hop)  in  the  tree,  where  FHs  are  currently 
to  be  found.  An  EH  also  may  keep  a  record  that  indicates  the 
number  and  type  of  floors  granted  to  each  receiver,  and  establish 
a  fairness  policy  based  on  service  priorities.  Eurthermore,  denied 
requests  may  be  queued  at  EH  and  held  pending,  until  they  can  be 
fulfilled,  or  are  timed  out.  Implicit  routing  allows  also  to  address 
coterie  members  in  a  floor-controlled  multicast  group  by  listing 
individual  labels  as  destinations,  which  is  also  an  elegant  solu¬ 
tion  to  the  anycasting  problem.  No  updates  regarding  the  position 
of  the  FC  and  FH  are  disseminated,  if  these  role  assignments  are 
static. 

On  the  average,  leaf  nodes  must  compare  more  bits  in  the 
control  routing  procedure,  than  nodes  close  to  the  root.  The  label 
cardinality  depends  on  the  tree  branching  factor  and  the  session 
size.  A  tree  with  n  session  participants  and  branching  factor  B 
has  logBU  levels,  with  log2n  bits  needed  for  node  labels.  The 
virtual  re-hanging  procedure  on  the  tree  may  cause  imbalances 
with  regard  to  the  average  pathlength  and  create  unfairness  in  the 
time-based  allocation  of  floors.  However,  since  spatio-temporal 
information  regarding  control  message  origin  is  available  to  the 
respective  FH,  floor  allocation  can  include  also  criteria  such  as 


distance  and  promote  uniform  treatment  of  stations.  A  basic  al¬ 
gorithm  for  labeling  and  routing  of  floor  control  messages,  in¬ 
cluding  only  FRQ  and  FRL  cases  and  separation  of  FC  and  FFl,  is 
shown  in  Figure  12. 


set  session  graph  S  <—  C s', 

set  floor  fiGFi—  state(resource  Vj)', 

/*  initialize  floors,  i  natural,  for  each  resource  */ 

protocol  HGCP  (); 
start  session  Cs 
LABEL.CONTROL.TREE  (S); 
while  Cs  is  running 
begin 

foreach  fi  do 

ROUTE.CONTROL_MESSAGE  (); 
end 

LABEL.CONTROL.TREE  (graph  G) 
begin 

construct  tree  T  C  E  from  G  with  root  r; 
set/(r)  =  1; 

LABEL3UBTREE(r,  T,  l(r)); 

end 

LABEL.SUBTREE  (node  s,  tree  T,  integer  P) 
begin 

set  Of  =  0; 

foreach  child  c  of  s  do 
set  l{c)  =  a  o  P; 
increment  a; 

LABEL.SUBTREE(c,  T,  1(c)); 

end 

ROUTE.CONTROL31ESSAGE  (tree  T,  node  x,  node  c,  directive  p) 
begin 

if  |/(*)|  >  |/(c)| 
or  if  \l  {x)  \  ^  prefix  of  |/(c)  | 
then  route  p  to  parent  of  x; 
else  ROUTE.CONTROLJVIESSAGE 

(  subtree(T),  children(x),  node  c,  directive  p); 

/*  multicast  to  the  children  of  x  with  matching  prefix  */ 
HANDLEJ^LOORJ)IRECTIVE(  node  x,  node  c,  directive  p); 
/*  if  local  node  is  destination,  handle  floor  directive  */ 

end 

HANDLE  JLOOR.DIRECTIVE  (node  x,  node  c,  directive  p) 
begin  /*  for  floor  f  */ 
case  p 

FRL:  if  c  ==  FC 

then  set  FH  =  nil', 

FRQ:  if  c  ==  FC  and  FH  ==  nil 
then  c  sends  FGT  to  x; 
else  if  c  =  =  FH 
orifFH  ^  nil 

then  FH  sends  FDY  to  coterie; 

/*  percolate  floor  busy  message  back  along  tree  */ 

end  case 

end 


Figure  12:  Basic  HGCP  Specification 


5  CONCLUSION 

Software  to  support  multiparty  interactivity  and  coordination  be¬ 
comes  more  important  with  improvements  in  networking  technol¬ 
ogy,  allowing  more  sophisticated  ways  of  telepresence  and  real¬ 
time  collaboration.  The  current  state-of-the-art  of  reliable  mul¬ 
ticast  uses  single  shared  acknowledgment  trees  to  warrant  scal¬ 
able  and  failure  free  message  dissemination  within  large  multicast 
groups.  A  primary  application  area  for  such  protocols  is  telecol¬ 
laboration,  however,  protocols  to  coordinate  large  groups  with  re¬ 
gard  to  resource  access  are  lacking.  This  paper  compared  known 
solutions  for  permission-  and  token-based  floor  control  and  de¬ 
scribed  the  first  tree-based  floor  control  protocol  embedded  with 
reliable  hierarchical  multicast.  An  implementation  and  further 
performance  assessment  are  under  way. 

6  ACKNOWLEDGMENTS 

This  work  was  supported  by  the  Defense  Advanced  Research 
Projects  Agency  (DARPA)  under  grant  F19628-96-C-0038. 


7  REFERENCES 


[1]  L.  Aguilar,  J.  J.  Garcia-Luna-Aceves,  D.  Moran,  E.J.  Craighill,  and 
R.  Brungardt.  Architecture  for  a  multimedia  teleconferencing  system. 
In  Proc.  ACM  SIGCOMM,  pages  126-136,  Aug.  1986. 

[2]  S.  R.  Ahuja  and  J.  R.  Ensor.  Coordination  and  control  of  multimedia 
conferencing.  IEEE  Comm.  Mag.,  30(5):38^3,  May  1992. 

[3]  E.  Amir,  S.  McCanne,  and  R.  Katz.  Receiver-driven  bandwidth  adap¬ 
tation  for  light-weight  sessions.  In  Proc.  ACM  Multimedia,  Seattle, 
WA,  Nov.  1997. 

[4]  D.  Bertsekas  and  R.  Gallager.  Data  networks.  Prentice  Hall,  Engle¬ 
wood  Cliffs,  N.J.,  2nd  edition,  1992. 

[5]  T.  Crowley,  P.  Milazzo,  E.  Baker,  H.  Forsdick,  and  R.  Tomlinson. 
MMConf:  An  infrastructure  for  building  shared  multimedia  applica¬ 
tions.  In  Proc.  ACM  CSCW,  pages  637-650,  Los  Angeles,  CA,  Oct. 
1990. 

[6]  S.  Deering.  Host  extensions  for  IP  multicasting.  RFC-1 112,  August 
1989. 

[7]  H.-P.  Dommel  and  J.  J.  Garcia-Luna-Aceves.  Efficacy  of  floor  control 
protocols  in  distributed  multimedia  collaboration.  Cluster  Computing, 
submitted  for  publication  1999. 

[8]  J.  J.  Garcia-Luna-Aceves,  E.  Craighill,  and  R.  Lang.  Floor  manage¬ 
ment  and  control  for  multimedia  conferencing.  In  Proc.  IEEE  Mul¬ 
timedia,  2nd  COMSOC  Int.  Multim.  Comm.  Worksh.,  Ottawa,  Can., 
Apr.  1989. 

[9]  E.  A.  Isaacs  and  J.  C.  Tang.  What  video  can  and  cannot  do  for  col¬ 
laboration:  a  case  study.  Multimedia  Systems  J.,  2(2):63-73,  Aug. 
1994. 

[10]  X.  Jia.  A  total  ordering  multicast  protocol  using  propagation  trees. 
IEEE  Trans.  Par.  and  Dist.  Sys.,  6(6):617-627,  June  1995. 

[1 1]  B.  N.  Levine  and  J.  J.  Garcia-Luna-Aceves.  Improving  internet  multi¬ 
cast  with  routing  labels.  In  Proc.  IEEE ICNP,  pages  241-250,  Atlanta, 
GA,  Oct.  1997. 

[12]  B.  N.  Levine,  D.  Lavo,  and  J.  J.  Garcia-Luna-Aceves.  The  case  for 
concurrent  reliable  multicasting  using  shared  ack  trees.  In  Proc.  ACM 
Multimedia,  Boston,  MA,  Nov.  1996. 

[13]  J.  Liebeherr  and  B.  S.  Sethi.  A  scalable  control  topology  for  multicast 
communication.  In  Proc.  IEEE  Infocom,  San  Francisco,  Mar./Apr. 
1998. 

[14]  J.  C.  Lin  and  S.  Paul.  RMTP:  A  reliable  multicast  transport  protocol. 
In  Proc.  IEEE  Infocom,  pages  1414—1425,  Mar.  1996. 

[15]  R.  Malpani  and  L.  Rowe.  Floor  control  for  large  MBone  seminars.  In 
Proc.  ACM  Multimedia,  pages  155-163,  Seattle,  WA,  Nov.  1997. 

[16]  T.  Maufer  and  C.  Semeria.  Introduction  to  IP  multicast  routing.  Inter¬ 
net  Draft,  URL  http://www.ietf.org/intemet-drafts/draft-ietf-mboned- 
intro-multicast-03.txt,  July  1997. 

[17]  M.  O.  Pendergast.  Multicast  channels  for  collaborative  applications: 
design  and  performance  evaluation.  Computer  Communication  Re¬ 
view,  23(2):25-38,  April  1993. 

[18]  K.  Raymond.  A  tree-based  algorithm  for  distributed  mutual  exclusion. 
ACM  Trans,  on  Comp.  Sys.,  7(l):61-77,  Feb.  1989. 

[19]  G.  Ricart  and  A.  K.  Agrawala.  An  optimal  algorithm  for  mutual  ex¬ 
clusion  in  computer  networks.  Comm.  ACM,  24(1),  1981. 

[20]  S.  Sarin  and  I.  Greif.  Computer-based  real-time  conferences.  IEEE 
Computer,  18(10):33^5,  Oct.  1985. 

[21]  K.  Srinivas,  R.  Reddy,  et  al.  MONET:  A  multimedia  system  for  con¬ 
ferencing  and  application  sharing  in  distributed  systems.  Technical 
report.  Concurrent  Engineering  Research  Center,  West  Virginia  Uni¬ 
versity,  Morgantown,  WV,  Feb.  1992.  CERC-TN-RN-91-009. 

[22]  H.  Takagi  and  L.  Kleinrock.  Output  processes  in  contention  packet 
broadcasting  systems.  IEEE  Trans.  Commun.,  COM  33(11):1191- 
1199,  1985. 

[23]  K.  Watabe,  S.  Sakata,  K.  Maeno,  H.  Fukuoka,  and  K.  Marbara.  Dis¬ 
tributed  multiparty  desktop  conferencing  system:  MERMAID.  In 
Proc.  ACM  CSCW,  pages  27-38,  Los  Angeles,  CA,  Oct.  1990. 

[24]  R.  Yavatkar,  J.  Griffioen,  and  M.  Sudan.  A  reliable  dissemination  pro¬ 
tocol  for  interactive  collaborative  applications.  In  Proc.  ACM  Multi- 
media,  pages  333-344,  San  Francisco,  Nov.  1995. 

[25]  R.  Yavatkar  and  K.  Lakshman.  Communication  support  for  distributed 
collaborative  applications.  Multimedia  Systems  J.,  2(2):74-88,  Aug. 
1994. 


